Translate from stackless bytecode and test inside rbpf #24
Conversation
| LLVMInitializeBPFTargetInfo(); | ||
| LLVMInitializeBPFTarget(); | ||
| LLVMInitializeBPFTargetMC(); | ||
| LLVMInitializeBPFAsmPrinter(); |
There was a problem hiding this comment.
It probably does not matter today, but we may soon want to start using the new SBF back-end here (LLVMInitializeSBF*) instead.
There was a problem hiding this comment.
Yes. At the moment I am using the old BPF target definitions, not sure how ready SBF2 is, but I expect to switch to SBF at some point since if the move backend is ever finished it will be well after SBF2 is deployed.
There was a problem hiding this comment.
As far as I know, the default back-end today is the SBF back-end. That is, I believe all of our ordinary production scripts should be using sbf-solana-solana. So at the moment, target sbf-solana-solana generates roughly the same code as target bpfel-unknown-unknown with +solana. The ELF e_machine values differ, of course (EM_BPF vs EM_SBF).
This new back-end is part of the overall transition away from BPF to SBF in our tools, scripts, etc (solana-labs/solana#19113). If by SBF2 you mean SBFv2 (solana-labs/solana#20323), some of that can be considered orthogonal work (enhancing/modifying the ISA, etc) to happen later.
There was a problem hiding this comment.
Thanks for the clarifications. I wasn't not sure what the distinction between sbfv1 and sbfv2 I had seen in the code were, nor that the tooling had already switched to the sbf target.
I filed an issue #33
| impl Target { | ||
| fn triple(&self) -> &'static str { | ||
| match self { | ||
| Target::Solana => "bpfel-unknown-unknown", |
There was a problem hiding this comment.
If/when llvm.rs changes to SBF back-end, this should become sbf-solana-solana.
This primarily does two things: add a translation from the "Move model" and its "stackless bytecode" to LLVM; and add an rbpf-based test harness.
The implementation can just do a few scalar ops, compile and link, and run inside rbpf, but the path is open to implement most typical codegen features that aren't specific to Move.
Translation from stackless bytecode is so far straightforward: it provides a list of local variables and a list of instructions that operate on them. In LLVM these locals are translated as allocas, and the move instructions as load/op/store sequences. LLVM's mem2reg pass should optimize these fine.
Running the rbpf-tests requires an installation of bpf-tools. Instructions for setting this up are in the readme.
There is a lot of obvious follow-on work to do and I'll file issues about them.
It may be easier to review individual patches than the entire patch at once.
Things to note:
script_into_modulepublicllvm-extra-syscrate to hold C++ LLVM glue code. At present it is only used to add the 'NoReturn' attribute tomove_rt_abort. I can see no way to do this via the C API. Whether the noreturn attribute matters much I am not clear: calls to this function are also followed by an 'unreachable' instruction.cc #21
cc #22
cc #23